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Foreword 



rd , 



This Technical Specification (TS) has been produced by the 3' Generation Partnership Project (3GPP). 

The present document is part 5 of a muhi-part TS covering the 3"* Generation Partnership Project: Technical 
Specification Group Services and System Aspects; Telecommunication Management; Configuration Management, as 
identified below: 

Part 1 : "3G Configuration Management: Concept and Requirements"; 

Part 2: "Notification Integration Reference Point: Information Service Version 1"; 

Part 3: "Notification Integration Reference Point: CORBA Solution Set Version 1:1"; 

Part 4: "Notification Integration Reference Point: CMIP Solution Set Version 1:1"; 

Part 5: "Basic Configuration Management IRP: Information Model Version 1"; 

Part 6: "Basic Configuration Management IRP CORBA Solution Set Version 1:1"; 

Part 7: "Basic Configuration Management IRP CMIP Solution Set Version 1:1"; 

Part 8: "Name Convention for Managed Objects". 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of the present document, it will be re-released by the TSG with an 
identifying change of release date and an increase in version number as follows: 

Version x.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 or greater indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, 
updates, etc. 

z the third digit is incremented when editorial only changes have been incorporated in the document. 



Introduction 



Configuration Management (CM), in general, provides the operator with the ability to assure correct and effective 
operation of the 3G-network as it evolves. CM actions have the objective to control and monitor the actual 
configuration on the Network Elements (NEs) and Network Resources (NRs), and they may be initiated by the operator 
or functions in the Operations Systems (OSs) or NEs. 

CM actions may be requested as part of an implementation programme (e.g. additions and deletions), as part of an 
optimisation programme (e.g. modifications), and to maintain the overall Quality of Service. The CM actions are 
initiated either as a single action on a NE of the 3G-network or as part of a complex procedure involving actions on 
many NEs. 

The interface Itf-N, defined in 3GPP TS 32.102 [2], for CM is built up by a number of Integration Reference Points 
(IRPs) and a related Name Convention, which realise the functional capabilities over this interface. The basic structure 
of the IRPs is defined in 3GPP TS 32.101 [1] and 3GPP TS 32.102 [2]. For CM, a number of IRPs (and the Name 
Convention) are defined herein, used by this as well as other Technical Specifications for Telecom Management 
produced by 3GPP. All these are included in Parts 2 and onwards in the 3GPP TS 32.106. 

The present document is Part 5 of 32. 106 - "Basic Configuration Management IRP: Information Model Version 1". 
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1 Scope 



The present document (Basic Configuration Management (CM) IRP: Information Model) defines an Integration 
Reference Point (IRP) through which an IRP Agent' (typically an Element Manager or Network Element) can 
communicate basic Configuration Management related information to one or several IRPManagers' (typically Network 
Managers). This version of the IRP is mainly intended for "passive management" of high-level network configuration 
and status information as required by a Network Manager. 

The present document is divided in three main parts: 

1. specifies a generic IRP Information Service with operations and notifications to be used by an TRPManager' 
to retrieve information on managed objects maintained by an 'IRP Agent'. 

2. specifies a generic Network Resource Model, NRM (also referred to as a Management Information Model - 
MIM) with definitions of Managed Object Classes. 

3. defines the UMTS management NRM by reusing this generic model either by direct reuse or sub-classing. 

The Configuration Management (CM) area is very large. The intention is to split the specification of the related 
interfaces in several IRPs. In addition to the subject IRP, it is expected that IRPs will be defined for functional areas like 
Security management. Software management. Network & Service provisioning, etc. An important aspect of such a split 
is that the Network Resource Models (NRMs) defined in different IRPs are consistent. The Basic CM IRP here provides 
a base for all CM-related resource modelling. 

To summarize, the Basic CM IRP has three main purposes: 

(1) to define an interface for retrieval of Configuration Management information, 

(2) to define a generic Network Resource Model that constitutes a base from which other (more specialized) 
resource models can inherit, and 

(3) to define the applied UMTS management Network Resource Model. 
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Definitions and abbreviations 



3.1 Definitions 

For the purposes of the present document, the following terms and definitions apply. For terms and definitions not 
found here, please refer to 3GPP TS 32.101 [1], 3GPP TS 32.102 [2] and 3GPP TS 32.106-1 [14]. 

Association: In general it is used to model relationships between Managed Objects. Associations can be implemented in 
several ways, such as: 

(1) name bindings , 

(2) reference attributes , and 

(3) association objects . 

This IRP stipulates that containment associations shall be expressed through name bindings, but it does not stipulate the 
implementation for other types of associations as a general rule. These are specified as separate entities in the object 
models (UML diagrams). Currently (in Release 99) however, all (non-containment) associations are modelled by means 
of reference attributes of the participating MOs. 

Managed Element (ME): An instance of the Managed Object Class G3ManagedElement. 

Managed Object (MO): In the context of the present document, a Managed Object (MO) is a software object that 
encapsulates the manageable characteristics and behaviour of a particular Network Resource. The MO is instance of a 
MO class defined in a MIM/NRM. An MO class has attributes that provide information used to characterize the objects 
that belong to the class (the term "attribute" is taken from TMN and corresponds to a "property" according to CIM). 
Furthermore, an MO class can have operations that represent the behaviour relevant for that class (the term "operation" 
is taken from TMN and corresponds to a "method" according to CIM). An MO class may support notifications that 
provide information about an event occurrence within a network resource. 

Management Information Base (MIB): A MIB is an instance of an NRM and has some values on the defined 
attributes and associations specific for that instance. In the context of the present document, an MIB consists of: 

(1) a Name space (describing the MO containment hierarchy in the MIB through Distinguished Names), 

(2) a number of Managed Objects with their attributes and 
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(3) 



a number of Associations between these MOs. Also note that TMN (ITU-T Recommendation X.710 [7]) 
defines a concept of a Management Information Tree (also known as a Naming Tree) that corresponds to the 
name space (containment hierarchy) portion of this MIB definition. Figure 1 depicts the relationships between 
a Name space and a number of participating MOs (the shown association is of a non-containment type) 




Namespace (containment hiCTaichy) 
O r^ MO V MIB 



o 



Association 



Figure 1 : Relationships between a Name space and a number of participating IVIOs 

Management Information Model (MIM): Also referred to as NRM - see the definition below. 

Name space: A name space is a collection of names. The IRP name convention (see 3GPP TS 32.106-8 [13]) restricts 
the name space to a hierarchical containment structure, including its simplest form - the one-level, flat name space. 
All Managed Objects in a MIB shall be included in the corresponding name space and the MIB/name space shall only 
support a strict hierarchical containment structure (with one root object). A Managed Object that contains another is 
said to be the superior (parent); the contained Managed Object is referred to as the subordinate (child). The parent of all 
MOs in a single name space is called a Local Root. The ultimate parent of all MOs of all managed systems is called the 
Global Root. 

Network Resource Model (NRM): A model representing the actual managed telecommunications network resources 
that a System is providing through the subject IRP. An NRM describes Managed Object Classes, their associations, 
attributes and operations. The NRM is also referred to as "MIM" (see above), which originates from the ITU-T TMN. 

Node B: A logical node responsible for radio transmission/reception in one or more cells to/from the User Equipment. 
It terminates the lub interface towards the RNC. 



3.2 



Abbreviations 



For the purposes of the present document, the following abbreviations apply: 

AUG Authentication Centre 

BG Border Gateway 

CIM Common Information Model 

CMIP Common Management Information Protocol 

CMIS Common Management Information Service 

CN Core Network 

CORBA Common Object Request Broker Architecture 

DMTF Distributed Management Task Force 

DN Distinguished Name (see 3GPP TS 32.106-8 [13]) 

EIR Equipment Identity Register 

EM Element Manager 

FM Fault Management 

GDMO Guidelines for the Definition of Managed Objects 

GGSN Gateway GPRS Support Node 

GMSC Gateway MSC 

GPRS General Packet Radio System 

HLR Home Location Register 

IDL Interface Definition Language 

lEC International Electro-technical Commission 

IETF Internet Engineering Task Force 

IRP Integration Reference Point 

ISO/IEC International Standards Organization 

ITU-T International Telecommunication Union, Telecommunication Sector 
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lub Interface between RNC and Node B 

LDAP Lightweight Directory Access Protocol 

NM Network Manager 

NE Network Element 

ME Managed Element 

MIB Management Information Base 

MIM Management Information Model 

MIT Management Information Tree (or Naming Tree) 

MO Managed Object 

MOC Managed Object Class 

MOF Managed Object Format 

MOI Managed Object Instance 

MSC Mobile Services Switching Centre 

NE Network Element 

NR Network Resource 

NRM Network Resource Model 

OSI Open Systems Interconnection 

PM Performance Management 

RDN Relative Distinguished Name (see 3GPP TS 32.106-8 [13]) 

RNC Radio Network Controller 

SGSN Serving GPRS Support Node 

SMI Structure of Management Information 

SMS Short Message Service 

SMS-GMSC SMS Gateway MSC 

SMS-IWMSC SMS Interworking MSC 

SNMP Simple Network Management Protocol 

SS Solution Set 

TMN Telecommunications Management Network 

UML Unified Modelling Language 

UMTS Universal Mobile Telecommunications System 

VLR Visitor Location Register 

WBEM Web-Based Enterprise Management 

XML extensible Mark-up Language 



4 System overview 

4.1 System context 

Figure 2 and Figure 3 identify system contexts of the subject IRP in terms of its implementation called IRP Agent and 
the user of the IRPAgent, called IRPManager. For a definition of IRPManager and IRP Agent, see 3GPP TS 32.102 [2]. 

The IRPAgent implements and supports the Basic CM IRP. The IRPAgent can be an Element Manager (EM) or a 
mediator that interfaces one or more NEs (see Figure 2), or it can be a Network Element (NE) (see Figure 3). In the 
former case, the interfaces (represented by a thick dotted line) between the EM and the NEs are not subject of this IRP. 

An IRPManager using this IRP shall choose one of the two System Contexts defined here, for each NE. For instance, if 
an EM is responsible for managing a number of NEs, the NM shall access this IRP through the EM and not directly to 
those NEs. For another IRP though, the System Context may be different. 
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Figure 2: System Context A 
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Figure 3: System Context B 
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4.2 Compliance rules 



For general definitions of compliance rules related to qualifiers (Mandatory/Optional/Conditional) for operations, 
notifications and parameters (of operations and notifications) please refer to 3GPP TS 32.102 [2]. 

The following defines the meaning of Mandatory and Optional MOC attributes and associations between MOCs, in 
Solution Sets to the Basic CM IRP: 

• The IRPManager shall support all mandatory attributes/associations. The IRPManager shall be prepared to 
receive information related to mandatory as well as optional attributes/associations without failure; however 
the IRPManager does not have to support handling of the optional attributes/associations. 

• The IRPAgent shall support all mandatory attributes/associations. It may support optional 
attributes/associations. 

An IRPAgent that incorporates vendor-specific extensions shall support normal communication with a 3GPP 
S A5-compliant IRPManager with respect to all Mandatory and Optional managed object classes, attributes, 
associations, operations, parameters and notifications without requiring the IRPManager to have any knowledge of the 
extensions. 

Given that 

• rules for vendor-specific extensions remain to be fully specified, and 

• many scenarios under which IRPManager and IRPAgent interwork may exist, 

it is recognised that in Release 4/5 the IRPManager, even though it is not required to have knowledge of vendor-specific 
extensions, may be required to be implemented with an awareness that extensions can exist and behave accordingly. 
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Modelling approach 



This clause identifies the modelling approach adopted and used in this IRP. 
As previously described, the IRP is structured in: 

(1) an IRP Information Model (the subject document) that specifies the interface in a protocol neutral manner, and 

(2) a number of IRP Solution Sets that provide the actual realization of the operations and notifications defined in 
the IRP Information Model for each protocol environment. 

Figure 4 shows the structure of the Basic CM IRP (including a number of possible Solution Sets). 



Basic Configuration Management IRP: Information model 



IRP Information Service - operations and notifications visible over the IRP. 
Network Resource Model (NRM) with MO classes (in UML) 




SNMP 

Solutio 

nSet 



LDAP 

Solutio 
n Set 



WBEM 

Solutio 

nSet 



CORBA 

Solutio 
n Set 



CMIP 

Solutio 

nSet 



Protocol 
independent 



Protocol 
specific 



Figure 4: Basic CIVI IRP Structure with example Solution Sets 

As shown in Figure 4, the IRP Information Model consists of two main parts: 

1. The IRP Information Service 

This is a specification of the operations and notifications that are visible over the IRP. These operations are generic 
in the sense that they do not specify the Managed Objects that are retrieved/manipulated over the interface. 

2. The Network Resource Model (NRM) 

This is a protocol-independent model that specifies a number of Managed Object classes (with attributes, 
operations and associations), which are relevant in the context of the subject IRP. Each Solution Set shall provide 
an implementation of this resource model with: 

a) references to standard models that are applicable for the corresponding protocol environment, and 

b) extensions to these standard models for the parts of the NRM that are not covered. 

The modelling approaches for these two aspects of the IRP are somewhat different and are described separately in the 
next two subclauses. 

5.1 IRP Information Service modelling approach 

The IRP Information Service of the subject IRP specifies a number of protocol-independent operations and notifications 
that are needed by an IRPManager to retrieve CM information from an IRP Agent. 
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The operations and notifications of the IRP Information Service are mainly based on the principles of the Common 
Management Information Service (CMIS) defined in ITU-T X.710 [7] and ITU-T X.721 [8] (M-GET etc.). Note 
however, that the Information Service of the subject IRP is focused on the operations and notifications needed for basic 
CM purposes and thus only covers a subset of the operations/notifications defined in ITU-T X.710 [7]/ITU-T X.721 [8]. 

It is expected that most Solution Sets will implement the operations and notifications by mapping them to standard 
operations (and possibly standard notifications) that are applicable in the corresponding protocol environment. 
The CMIP Solution Set should for instance map the operations to the more generic operations defined in CMIS, an 
SNMP Solution Set should map the operations to applicable SNMP operations, and the CORBA Solution Set should 
map the operations to applicable OMG/CORBA services. 

5.2 Network Resource Modelling approach 

The NRM defined in the subject IRP bases its design mainly on work captured in ITU-T M.3100 [4], [5], [6]. However, 
as described in the Scope of the present document (clause 1): The model is highly simplified for the purpose of the NM, 
based on the assumption that all of the detailed CM actions, including fault correction after one or more alarms, are 
performed by an Element Manager which knows the vendor-specific NRM and configuration, and which is launched by 
the NM when necessary. 

Moreover, the classes defined herein are very basic, only for the necessary support of Fault Management (FM) and 
Performance Management (PM), which means that they contain very few attributes - basically only for naming. 

In addition, also some basic associations between some of the classes are defined. 

The NRM is split into a generic and an UMTS-specific part. 

Detailed mapping to the actual standard model is described in each Solution Set. It is important to note that if one 
selects a specific management protocol, one should also as base use existing de-facto conventions and standard resource 
models that are applicable to that protocol environment. Examples: 



• 



• 



SNMP Solution Sets (SMI-specifications) should be consistent with existing standard SNMP MIB-modules in 
order to function in an SNMP environment. 

CMIP Solution Sets (GDMO-specifications) should be based on standard models like ITU-T X.721 [8] and ITU- 
T M.3100 [4], [5], [6] in order to function in an OSI/TMN environment. 

WBEM Solution Sets (MOF/XML-specifications) should be based on CIM to function in a WBEM 
environment. 



NOTE: CORBA Solution Sets are special in the sense that no such corresponding de-facto standard models exist, 
and CORBA/IDL is transparent to any model. Thus, one has full freedom to choose the same model for 
the CORBA Solution Set to this IRP, as the IRP Information Model defined herein. 

Finally, all solution sets shall of course be consistent with the IRP Information Model defined herein. 



6 IRP Information IVIodel 

6.1 Introduction 

As already introduced in the previous clause, the present clause defines the Basic CM IRP Information Model in the 
form of the IRP Information Service and the Network Resource Model (split into a generic and an UMTS-specific part). 

The corresponding Solution Set specifications provide protocol dependent object models. They provide the actual 
realization of the operations and notifications defined in this subclause in each protocol environment. One may find that 
the operation names and operation parameters defined in the protocol-neutral model differ from those defined in the 
Solution Sets (e.g. due to mappings to existing standard models that are applicable for a specific Solution Set). 
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6.2 



IRP Information Service 



This subclause specifies the operations and notifications that are visible over this IRP. These operations are generic in 
the sense that they do not specify the MOs that are retrieved/manipulated over the interface. 



6.2.1 



Interfaces 



Figure 5 illustrates the operations and notifications defined as interfaces implemented and used by IRP Agent and 
IRPManager, described using UML notation (Interface in IRP Information Model is identical to concepts conveyed by 
stereotype «interface» of UML). Parameters and return status are not indicated. 

Two interfaces are defined. One is called BasicCmlRPOperations. This interface defines operations implemented 
by IRP Agent and used (or called) by IRPManager. The other is called BasicCmlRPNotif ications. This interface 
defines notifications implemented by IRPManager and used by IRP Agent. 



IRP Man age 



«lnterface» 
BasicCmlRPOperation 



%etMoAttributes() 
^etContainmentO 
%etBasicCmlRPVersion() 






«lnterface» 
BasicCmlRPNotification 



%iotifyObjectCreation() 
*wiotifyObjectDeletion() 
Notify Attribute ValueChangeO 



IRPAgent 



Figure 5: UIVIL Interface Class Diagram 



6.2.2 Operations 



6.2.2.1 



Operation getMoAttributes (M) 



This operation is invoked by IRPManager to request the retrieval of management information (Managed Object 

attribute names and values) from the MIB maintained by IRPAgent. One or several Managed Objects may be retrieved - 

based on the containment hierarchy. The operation corresponds to the M-GET service defined by CMIS (ITU-T X.710 

[7]). 

A Solution Set may choose to split this operation in several operations (e.g. operations to get "handlers" or "iterators" to 

Managed Objects fulfilling the scope/filter criteria and other operations to retrieve attribute names/values from these 

"handlers"). 
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Table 1 : Parameters of getMoAttributes 



Name 


Qualifier 


Description 


baseObject In stance 


Input, M 


The MO where the search starts. This is a full Distinguished Name according to 
3GPPTS 32.106-8 [13]. 


scope 


Input, M 


This parameter defines how many levels of the containment hierarchy to search 
(i.e. apply the filter defined below). The search starts from the MO given by the 
baseOb jectinstance parameter. The levels of search that may be performed 
are: 

• the base object alone (default); 

• the n-th level subordinates of the base object; 

• the base object and all of its subordinates down to and including the n-th 
level; 

• the base object and all of its subordinates. 


filter 


Input, M 


This parameter defines a filter test to be applied to the scoped Managed 
Object(s). If the filter is empty, all of the managed objects included by the scope 
are selected. 

The actual syntax and capabilities of the filter is Solution Set specific. However, 
each Solution Set support a filter consisting of one or several assertions that may 
be grouped using the logical operators AND, OR and NOT. Each assertion is a 
logical expression of attribute existence, attribute value comparison ("equal to X, 
less than Y" etc.) and MO Class. 


at tribute List In 


Input, M 


This parameter identifies the attributes to be returned by this operation. In R99, 
only the semantics "Return all attributes" shall be supported. An empty list means 
"Return all attributes". For future releases the possibility to specify a list of 
attributes is expected. 


managedObject Class 


Output, M 


For each returned MO: The class of the MO. 


managedOb ject Instan 
ce 


Output, M 


For each returned MO: The name of the MO. This is a full Distinguished Name 
according to 3GPP TS 32.106-8 [13]. 


attributeListOut 


Output, M 


For each returned MO: A list of name/value pairs for the MO attributes. 


status 


Output, M 


(a) Operation succeeded, or 

(b) Operation failed because of specified or unspecified reason. 



6.2.2.2 Operation getContainment (O) 

This (optional) operation is only intended for retrieval of the containment relations from the MIB. 

The output parameter 'containment' of the operation shall contain a list of all Managed Object instances in the MIB 
maintained by IRP Agent (or a subset starting from a given base object) including containment information (naming 
tree). 

The structure and format of the output parameter 'containment' are Solution Set dependent. 

Table 2: Parameters of getContainment 



Name 


Qualifier 


Description 


baseObject 
Instance 


Input, M 


The MO where the search starts. This is a full Distinguished Name according to 
3GPPTS 32.106-8 [13]. 


scope 


Input, 


This parameter gives a value N defining how many levels of the containment 
hierarchy from the baseObjectlnstance to include in the result. 
The levels of inclusion that may be performed are: 

• the base object alone (default); 

• the n-th level subordinates of the base object; 

• the base object and all of its subordinates down to and including the n-th level; 

• the base object and all of its subordinates. 


containment 


Output, M 


A list of DN of all Managed Object instances that satisfy the scope. 


status 


Output, M 


(a) Operation succeeded, or 

(b) Operation failed because of specified or unspecified reason. 
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6.2.2.3 



Operation getBasicCmlRPVersion (M) 



IRPManager wishes to find out the Basic CM IRP SS version(s) supported by IRP Agent. IRP Agent shall respond with 
a list of supported Basic CM IRP SS versions. Since the present document defines the first IRP version, 
implementation of IRP Agent in compliance to this version shall return with one version number in the list. 

Table 3: Parameters of getBasicCmiRPVersion 



Name 


Qualifier 


Description 


versionNumberList 


Output, M 


It indicates one or more SS version numbers supported by the IRPAgent. 
This shall in Release 99 contain only one version number. 


status 


Output, M 


(a) Operation succeeded in that versionNumberList contains valid result. 

(b) Operation failed. Output parameter versionNumberList may contain invalid 
result. 



6.2.3 Notifications 



6.2.3.1 



General 



Operations that IRPManager uses to manage subscription to receive notifications are specified in Notification IRP IS 
3GPP TS 32.106-2 [3], which also specifies a generic notification notify. Notification IRP IS (3GPP TS 32.106-2 
[3]) defines a number of parameter-attributes that are commonly carried in notifications as well. 

The commonly carried parameter-attributes are collectively called notif icationHeader in the present document. 
The parameter-attribute names and their qualifiers are listed in Table 4. 

Table 4: Notification Header 



Parameter-Attributes defined in 3GPP TS 32.106-2 [3] 


Qualifier for use in this IS 


managedObject Class 


M 


managedObject Instance 


M 


notif icationid 





eventxime 


M 


systemDN 


C 


eventType 


M 


extendedE vent Type 


M 



The following subclauses define specific notifications relevant for Basic CM IRP by extending notify in Notification 
IRP IS (3GPP TS 32.106-2 [3]). 



6.2.3.2 



Notification notifyObjectCreation (O) 



IRPAgent notifies the subscribed IRPManager that a new Managed Object has been created and that the new object 
satisfies the filter constraint expressed in IRPManager's subscribe operation (see 3GPP TS 32.106-2 [3]). This 
notification is based on the ob jectCreation notification type specified in ITU-T X.721 [8] and ITU-T X.730 [9] 
(difference compared to these specifications are indicated in the description below). 

When a notifyObjectCreation notification is received, that in the MOI Parameter- Attribute includes superior 
(parent) MO(s) that the IRPmanager is not aware of (in case the object creation notifications for that or those objects 
have not been received yet, or are lost), these superior MO(s) shall also be assumed to be created. 
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Table 5: Parameters for notifyOb jectcreation 



Name 


Qualifier 


Description 


notif icationHeader 


Input, M 


See Table 4: Notification Header. 


correlatedNotif ications 


Input, 


A set of notifications that are correlated to the subject notification. 
Defined in ITU-T X.733 [10]. 


additionalText 


Input, 


It can contain further information on the creation of the IVIO. 


source Indicator 


Input, 


This parameter, when present, indicates the source of the operation that 
led to the generation of this notification. It can have one of the following 
values: 

• resource operation: The notification was generated in response to 
an internal operation of the resource; 

• management operation: The notification was generated in response 
to a management operation applied across the managed object 
boundary external to the managed object; 

• unknown: It is not possible to determine the source of the operation. 


attributeList 


Input, 


The attributes (name/value pairs) of the created MO. 



6.2.3.3 



Notification notifyObjectDeletion (O) 



IRP Agent notifies the subscribed IRPManager of a deleted Managed Object. The IRP Agent invokes this notification 
because the subject notification satisfies the fiher constraint expressed in the IRPManager subscribe operation (see 
3GPP TS 32.106-2 [3]). This notification is based on the ob jectDeletion notification type specified in ITU-T 
X.721 [8] and ITU-T X.730 [9] (difference compared to these specifications are indicated in the description below). 

When a Managed Object is notified as deleted, all subordinate Managed Objects (i.e. the complete sub-tree of contained 
MOs under the deleted MO), if any exist, shall also be assumed to be deleted. When an IRP Agent is able to detect an 
atomic operation leading to the removal of a whole sub-tree of the MIB, it shall send a delete notification for only the 
top MO of the deleted sub-tree. Furthermore, all associations to a deleted Managed Object shall be deleted by the 
IRPAgent. 

Table 6: Parameters for notifyObjectDeletion 



Name 


Qualifier 


Description 


notif icationHeader 


Input, IVI 


See Table 4: Notification Header. 


correlatedNotif ications 


Input, 


A set of notifications that are correlated to the subject notification. 
Defined in ITU-T X.733 [10]. 


additionalText 


Input, 


It can contain further information on the deleted IVIO. 


source Indicator 


Input, 


This parameter, when present, indicates the source of the operation that 
led to the generation of this notification type. It can have one of the 
following values: 

• resource operation: The notification was generated in response to 
an internal operation of the resource; 

• management operation: The notification was generated in response 
to a management operation applied across the managed object 
boundary external to the managed object; 

• unknown: It is not possible to determine the source of the operation. 


attributeList 


Input, 


The attributes (name/value pairs) of the deleted MO. 



6.2.3.4 



Notification notifyAttributeValueChange (O) 



IRPAgent notifies the subscribed IRPManager of a change of one or several attributes of a Managed Object in the 
NRM. The IRPAgent invokes this notification because the subject notification satisfies the filter constraint expressed in 
the IRPManager subscribe operation (see 3GPP TS 32.106-2 [3]). This notification is based on the 
attributeValueChange notification type specified in ITU-T X.721 [8] and ITU-T X.730 [9] (difference 
compared to these specifications are indicated in table 7). 
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Table 7: Parameters for notifyAttributeValueChange 



Name 


Qualifier 


Description 


notif icationHeader 


Input, M 


See Table 4: Notification Header. 


correlatedNotif ications 


Input, 


A set of notifications that are correlated to the subject notification. 
Defined in ITU-T X.733 [10]. 


additionalText 


Input, 


It can contain further information on the attribute change of the IVIO. 


source Indicator 


Input, 


This parameter, when present, indicates the source of the operation that 
led to the generation of this notification type. It can have one of the 
following values: 

• resource operation: The notification was generated in response to 
an internal operation of the resource; 

• management operation: The notification was generated in response 
to a management operation applied across the managed object 
boundary external to the managed object; 

• unknown: It is not possible to determine the source of the operation. 


attributeValueChange 
Definition 


Input, M 


The changed attributes (name/value pairs) of the IVIO (with both new 
and, optionally, old values). 



6.3 Generic Network Resource Model (NRM) 

This subclause defines the generic managed object classes supporting the Basic CM IRP. These object classes are 
protocol environment neutral and the model does not define the syntax or encoding of the operations and parameters. 

The model described in this subclause allows for Managed Elements to be defined for management purposes according 
to the functionality contained within them. As an example, a single implementation of a combined MSC and VLR may 
be required. However, in the implementation it is required to create a single interface for the management of this 
element. This is expected to be achieved by instantiating a G3ManagedElement MOC that contains the 
"mscFunction" MOC, the "vkFunction" MOC (as in the GSM 12.xx-series of specifications), and other generic or non- 
UMTS specific MOCs as appropriate to define the manageable capability of that managed element. See also the 
managedElementType attribute in the G3ManagedElement MOC definition. 

It should be noted that, although this model allows for combined managed element functionality as described above, in 
this subclause only the high-level and generic MOCs are defined. UMTS MOCs modelling more specific managed 
element functionality are defined in subclause 6.4. 

6.3.1 Managed Object Class (MOC) diagrams 
6.3.1 .1 Inheritance hierarchy 

Figure 6 shows the inheritance hierarchy for the generic MO classes defined in this IRP. 
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GSSubNetwork 



MeContext 



ManagementNode 



GSManagedElement 



IRPAgent 

(from Interface Service) 



ManagedFunction 



NotificationIRP 



AlarmlRP 



BasicCmIRP 



Figure 6: Generic NRIVI Inheritance l-iierarchy 

6.3.1 .2 Containment/Naming and Association diagram 

Figure 7 shows the containment/naming hierarchy and the associations of the generic MO classes defined by this IRP. 

NOTE: The Managed Object containment/naming relationships are in the diagram(s) below indicated by UML 
"Aggregation by reference" ("hollow diamonds"). 
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MgmtAssodation 




IRPAgent 

(from Interface Service) (\ * /RQQ' f) 11 




{R99: 0..1} 
BasicCmIRP 



NOTE 1 : G3ManagedElement may be contained in eitiier a G3SubNetwork or an MeContext instance, or have no parent 

instance at all. 
NOTE 2: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 

Figure 7: Generic NRIVI Containment/Naming and Association diagram 

Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.106-8 [13] that 
expresses its containment hierarchy. As an example, the DN of a Managed Element instance could have a format like: 

g3SubNetwork=Sweden,meContext=MEC-Gbg-l, g3ManagedElement=RNC-Gbg-l . 



6.3.2 Managed Object Class (MOC) definitions 

A general note regarding all the notification tables defined for each MOC below: Each MOC may potentially send the 
notifications listed in the notification table for the MOC. The notifications with qualifier (M) shall be supported by the 
MOC, and the notifications with qualifier (O) may be supported by the MOC. 

For example, if Notification notifyObjectCreation defined in Basic CM IRP has the qualifier (M), then if a MOC is 
defined such that it emits such a notification, this notification shall be emitted when appropriate (i.e. when a new object 
is created). If Notification notifyChangedAlarm has the qualifier (O) in Alarm IRP (see 3GPP TS 32. 111-2 [11]), then if 
a MOC is defined such that it emits such a notification, this notification may or may not be emitted when appropriate. 

Further, if a notification in the qualifier column (of the MOC notification tables) has a reference to another 
specification, it means that the qualifier for the notification is specified in the referred specification. 
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6.3.2.1 



MOC GSSubNetwork 



This Managed Object Class represents a set of managed entities as seen over the Itf-N. 

A G3SubNetwork may have 0...N instances. It shall be present if either a ManagementNode or multiple 
G3ManagedElements are present (i.e. ManagementNode and multiple G3ManagedElement instances shall have 
G3SubNetwork as parent). Restriction in R99: N=l. 

Table 8: Attributes of GSSubNetwork 



Name 


Qualifier 


Description 


gSSubNetworkId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when 
naming an instance of the G3SubNetworl< object class. This 
RDN uniquely identifies the object instance within the scope of 
its containing (parent) object instance. 


dnPref ix 


READ- ONLY, C 


It carries the DN Prefix information as defined in Annex C of 
32.106-8 [13]. It shall only be specified if the instance of 
GSSubNetwork is a local root instance of the MIB. Otherwise the 
value shall carry the NULL semantics. 


userLabel 


READ- ONLY, M 


A user-friendly (and user assigned) name of the associated 
object. 



Table 9: Notifications of GSSubNetwork 



Name 


Qualifier 


Notes 


notif yAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.3.2.2 



MOC G3ManagedElement 



This Managed Object Class represents telecommunications equipment or TMN entities within the telecommunications 
network that performs Managed Element (ME) functions, i.e. provides support and/or service to the subscriber. 
An ME communicates with a manager (directly or indirectly) over one or more interfaces for the purpose of being 
monitored and/or controlled. MEs may or may not additionally perform element management functionality. 
An ME contains equipment that may or may not be geographically distributed. An ME is often referred to as a 
"Network Element". This class is similar to the Managed Element class specified in ITU-T M.3100 [4], [5], [6]. 

A G3ManagedElement may be contained in either a G3SubNetwork or in an MeContext instance. A single 
G3ManagedElement seen over the Itf-N may also exist stand-alone with no parent at all. 

As mentioned in the introduction to subclause 6.3 (the generic model), the G3ManagedElement MOC may be used to 
represent combined ME functionality (as indicated by the managedElementType attribute and the contained instances of 
different functional MOCs). 

Single function G3ManagedElement managed object instances will have a 1..1 containment relationship to a function 
Managed Object (in this context a function MO is an MO derived from the ManagedFunction MOC). Multiple function 
G3ManagedElement managed object instances will have a 1..N containment relationship to function Managed Objects. 

It should be noted that although the present document only models UMTS specific functionality with some UTRAN 
related MOCs, the G3ManagedElement MOC may still be used to represent other ME types than RNC or NodeB, e.g. 
an MSC or a combined MSC/HLRA^LR. 
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Table 10: Attributes of GSIVIanagedElement 



Name 

gSManagedElementId 



Qualifier 

READ-ONLY, M 



Description 

An attribute whose 'name+value' can be used as an RDN when naming 
an instance of the GSIVIanagedElement object class. This RDN uniquely 
identifies the object instance within the scope of its containing (parent) 
object instance 



dnPref ix 



READ- ONLY, 



It carries the DN Prefix information as defined in Annex C of 32.106-8 
[1 3]. It shall only be specified if the instance of GSIVIanagedElement is a 
local root instance of the IVIIB. Otherwise the value shall carry the NULL 
semantics. 



managedElementType READ-ONLY, M 



The type of managed element. It is a multi-valued attribute with one or 

more elements. Thus, it may represent one ME functionality, e.g. an 

RNC, or a combination of more than one functionality e.g. an 

MSC/HLR. The allowed members of this attribute are: 

RNC, NodeB, IVISC, HLR, VLR, AUG, EIR, SMS-IVVMSC, SIVIS-GMSC, 

GMSC, SGSN, GGSN and BG. 

The actual syntax and encoding of this attribute is Solution Set specific. 



userLabel 



READ-ONLY, IVI 



A user-friendly name of this object. 



vendorName 



READ-ONLY, IVI 



The name of the GSIVIanagedElement vendor. 



userDefinedState 



locationName 



READ-ONLY, M 



READ-ONLY, IVI 



An operator defined state for operator specific usage. (See also Note 

below) 

The physical location of this entity (e.g. an address). 



managedBy 



READ-ONLY, IVI 



The value of this attribute shall be the DN of the related 
managementNode instance. This is a reference attribute modelling the 
role (of the association MgmtAssociation) that this IVIE is managed by 
0-1 managementNode. 



NOTE: In addition to the userDefinedState, 
release. 



state management attributes are expected to be included in the next 



Table 1 1 : Notifications of G3ManagedElement 



Name 


Qualifier 


Notes 


notif yAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.3.2.3 



MOC MeContext 



This Managed Object Class (MOC) is introduced for naming purposes. It may support creation of unique DNs in 
scenarios when some MEs have the same RDNs due to the fact that they have been manufacturer pre-configured. 
If some MEs have the same RDNs (for the above mentioned reason) and they are contained in the same GSSubNetworlc 
instance, some measure shall be taken in order to assure the global uniqueness of DNs for all MOIs under those MEs. 
One way could be to set different DnPrefixes for those NEs, but that would require either that: 

a) all LDNs or DNs are locally modified using the new DnPrefix for the upper portion of the DNs, or 

b) a mapping (translation) of the old LDNs or DNs to the new DNs every time they are used externally, e.g. in alarm 
notifications. 

As both the two alternatives above may involve unacceptable drawbacks (as the old RDNs for the MEs then would have 
to be changed or mapped to new values), using MeContext offers a new alternative to resolve the DN creation. Using 
MeContext as part of the naming tree (and thus the DN) means that the DnPrefix, including a unique MeContext for 
each ME, may be directly concatenated with the LDNs, without any need to change or map the existing ME RDNs to 
new values. 

MeContext have 0..N instances. It may exist even if no G3SubNetwork exists. Every instance of MeContext contains 
exactly one G3ManagedElement during steady-state operations. 
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Table 12: Attributes of MeContext 



Name 


Qualifier 


Description 


meContextId 


READ-ONLY, M 


An attribute whose 'name-nvalue' can be used as an RDN when naming an instance of 
this object class. This RDN uniquely identifies the object instance within the scope of 
its containing (parent) object instance. 


dnPref ix 


READ- ONLY, 


It carries the DN Prefix information as defined in Annex C of 3GPP TS 32.106-8 [13]. 
It shall only be specified if the instance of MeContext is a local root instance of the 
MIB. Otherwise the value shall carry the NULL semantics. 



Table 13: Notifications of MeContext 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.3.2.4 



MOC ManagementNode 



This Managed Object Class represents a telecommunications management system (EM) within the TMN that contains 
functionality for managing a number of Managed Elements (MEs). The management system communicates with the 
MEs directly or indirectly over one or more interfaces for the purpose of monitoring and/or controlling these MEs. 

This class has similar characteristics as the G3ManagedElement. The main difference between these two classes is that 
the ManagementNode has a special association to the managed elements that it is responsible for managing. 

Table 14: Attributes of ManagementNode 



Name 


Qualifier 


Description 


management Node Id 


READ-ONLY, M 


An attribute whose 'name-i-value' can be used as an RDN when 
naming an instance of this object class. This RDN uniquely 
identifies the object instance within the scope of its containing 
(parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly name of this object. 


vendorName 


READ-ONLY, M 


The name of the IVIanagementNode vendor. 


userDef inedState 


READ-ONLY, M 


An operator defined state for operator specific usage. 


locationName 


READ-ONLY, M 


The physical location of this entity (e.g. an address). 


manages 


READ-ONLY, M 


The value of this attribute shall be a list of the DN(s) of the related 
ManagedElement instance(s). This is a reference attribute 
modelling the role (of the association MgmtAssociation) that this 
managementNode is responsible for managing 0-N MEs. 



Table 15: Notifications of ManagementNode 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 










not if yAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not if yClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyOb ject Creation 







notifyOb jectDeletion 








£75/ 



3GPP TS 32.106-5 version 3.1.0 Release 1999 



23 



ETSI TS 132 106-5 V3.1.0 (2001-03) 



6.3.2.5 



MOC ManagedFunction 



This Managed Object Class is similar to the class gsmManagedFunction defined in GSM 12.20 [12] and is 
provided for sub-classing only. It provides the attributes that are common to functional MO classes. Note that a 
Managed Element may contain several managed functions. The ManagedFunction may be extended in the future if 
more common characteristics to functional objects are identified. 

Table 16: Attributes of ManagedFunction 



Name 


Qualifier 


Description 


userLabel 


READ-ONLY, M 


A user-friendly name of the associated object. 



6.3.2.6 MOC IRPAgent 

This Managed Object Class represents the functionality of an IRPAgent. It shall be present. For a definition of 
IRPAgent, see 3GPP TS 32.102 [2]. 

Restriction in R99: The IRPAgent will be contained under a managed object as follows (only one of the options shall be 
used): 

1 . ManagementNode, if the configuration contains a ManagementNode (see Config #1 and Config #2 in Figure A. 1 ). 

2. G3SubNetwork, if the configuration contains a G3SubNetwork and no ManagementNode (see Config #3 in Figure 
A.1). 

3. G3ManagedElement, if the configuration contains no ManagementNode or G3SubNetwork (see Config #4 in 
Figure A. 1). 

Table 17: Attributes of IRPAgent 



Name 


Qualifier 


Description 


irpAgentId 


READ-ONLY, M 


An attribute wliose 'name+value' can be used as an RDN wlien naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


systemDN 


READ-ONLY, C 


The Distinguished Name (DN) of IRPAgent. Defined in 3GPP TS 32.106-2 [3]. 



Table 18: Notifications of IRPAgent 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not ifyAlarmLi St Rebuilt 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








Note that these notifications are issued based on occurrences on the IRPAgent MOC and not on occurrences on other 
Basic CM IRP managed objects. 

6.3.2.7 MOC Notif icationIRP 

This Managed Object Class represents the Notification IRP capability associated with each IRPAgent. At least one 
instance shall be present for every IRPAgent instance. Restriction in R99: Number of instances = 1. 
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Table 19: Attributes of Notificationiiup 



Name 


Qualifier 


Description 


notif icationlRPId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Notification IRP version entries. 



6.3.2.8 MOC AlarmlRP 

This Managed Object Class represents the Alarm IRP (see 3GPP TS 32. Ill -2 [11]) capability associated with each 
IRP Agent. Restriction in R99: Number of instances = 0..1. 

Table 20: Attributes of AlarmiRP 



Name 


Qualifier 


Description 


alarmlRPId 


READ-ONLY, M 


An attribute whose 'name-nvalue' can be used as an RDN when naming an instance 
of this object class. This RDN uniquely identifies the object instance within the 
scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Alarm IRP (see 3GPP TS 32.111-2 [11]) version entries. 



6.3.2.9 MOCBasicCmiRP 

This Managed Object Class represents the Basic CM IRP capability associated with each IRP Agent. Restriction in R99: 
Number of instances = 0..1. 







Table 21 : Attributes of BasicCmiRP 


Name 


Qualifier 


Description 


basicCmlRPId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


irpVersion 


READ-ONLY, M 


One or more Basic CM IRP version entries. 



6.3.3 Associations 



6.3.3.1 



Association MgmtAssociation (M) 



This association is used to represent relationships between one or more MEs and the ManagementNode that is 
responsible for managing the MEs. It has two roles, named Manages and ManagedBy. The role 'Manages' models the 
fact that a ManagementNode is responsible for managing zero or more MEs, and the role ManagedBy models the fact 
that an ME is managed by zero or one ManagementNode. Each role is in the MOC definition mapped to a reference 
attribute with the same name. 

6.4 UMTS Network Resource Model (NRM) 

This NRM includes the generic model defined in subclause 6.3, and in addition it is expected to define MOCs 
modelling the functionality in one or more of the Managed Elements. However, in Release 99 only a more detailed 
model is defined for UTRAN specific functionality. 

These object classes are protocol environment neutral and the model does not define the syntax or encoding of the 
operations and parameters. 
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6.4.1 Managed Object Class (MOC) diagrams 

A general note regarding all the notification tables defined for each MOC below: Each MOC may potentially send the 
notifications listed in the notification table for the MOC. The notifications with qualifier (M) shall be supported by the 
MOC, and the notifications with qualifier (O) may be supported by the MOC. 

For example: If Notification notifyObjectCreation defined in Basic CM IRP has the qualifier (M), then if a MOC is 
defined such that it emits such a notification, this notification shall be emitted when appropriate (i.e. when a new object 
is created). If Notification notifyChangedAlarm has the qualifier (O) in Alarm IRP (see 3GPP TS 32.111-2 [11]), then if 
a MOC is defined such that it emits such a notification, this notification may or may not be emitted when appropriate. 

Further, if a notification in the qualifier column (of the MOC notification tables) has a reference to another 
specification, it means that the qualifier for the notification is specified in the referred specification. 

6.4.1 .1 Inheritance hierarchy 

Figure 8 shows the inheritance hierarchy for the UMTS NRM. Only new MOCs compared to subclause 6.3, and MOCs 
inherited from the generic model, are shown here. 



£75/ 



3GPP TS 32.106-5 version 3.1.0 Release 1999 



26 



ETSI TS 132 106-5 V3.1.0 (2001-03) 



ManagedFunction 

(from Generic Model) 





/ 


\ 




RncFunction 






SmslwmscFunction 














UtranCell 






SmsGmscFunction 














lubLink 






SgsnFunction 














NodeBFunction 






GgsnFunction 














MscFunction 






BgFunction 














HIrFunction 






AucFunction 














VIrFunction 






EirFunction 




















GmscFunction 





Figure 8: UIUITS NRIUI Inheritance l-iierarchy 

6.4.1 .2 Containment/Naming and Association diagrams 

Figures 9 and 10 show the containmentynaming hierarchy and the associations of the UMTS NRM defined by this IRP. 

NOTE: The Managed Object containment/naming relationships are in the diagram(s) below indicated by UML 
"Aggregation by reference" ("hollow diamonds"). 
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+Manages 
0..* 



{R99:0..1 



ManagementNode 

(from Generic Model) 



{R99:0..1) 




IRPAgent 

(from Interface Service) 



RncFunction 



0..* I {R99:*=0} 
GSSubNetwork 

(from Generic Model) 



GSManagedElement +ManagedBy 



(from Generic Ivlodei) 





MgirtAssociation 



0..* 



ConnectedTo 

+NodeBFunction-lubLink NodeBFunction 



lubLink-NodeBFunction 



0..1 



0..1 

+lubLink-UtianCell 



UtranCell-lubLink 



NOTE 1 : G3ManagedElement may be contained in either a GSSubNetwork or an MeContext instance, or have no parent 

instance at all. 
NOTE 2: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 

creation and deletion scenarios. 
NOTE 3: The containment of MOCs NotificationIRP, AlarmlRP and BasicCmIRP under IRPAgent, which is shown in the 

generic model in subclause 6.3, is valid for this model as well. 

Figure 9: UIVITS NRIV! Containment/Naming and Association diagram, Networl<-UTRAN view 



Each Managed Object is identified with a Distinguished Name (DN) according to 3GPP TS 32.106-8 [13] that 
expresses its containment hierarchy. As an example, the DN of a Managed Object representing a cell could have a 
format like: 

g3SubNetwork=Sweden,meContext=MEC-Gbg-l, g3ManagedElement=RNC-Gbg-l, rncFunction=RF-l, utranCell=Gbg- 
1. 



£75/ 



3GPP TS 32.106-5 version 3.1.0 Release 1999 



28 



ETSI TS 132 106-5 V3.1.0 (2001-03) 



MscFunction O--'' 



HIrFunction 0--1 



VIrFunction 



AucFunction O-l 



EirFunction 



GSManagedElement 

(from Generic Model) 




0..1 SmslwmscFunction 



0..1 SmsGmscFunction 



SgsnFunction 



GgsnFunction 



BgFunction 



NOTE: The listed cardinality numbers represent transient as well as steady-state numbers, and reflect all managed object 
creation and deletion scenarios. 

Figure 10: UIUITS NRIUI Containment/Naming and Association diagram, CN view 

6.4.2 UMTS specific Managed Object Class (MOC) definitions 



6.4.2.1 



MOC RncFunctioi 



This Managed Object Class represents RNC functionality. For more information about the RNC, see 3GPP TS 23.002 
[15]. 



It inherits from ManagedFunction. 



Table 22: Attributes of RncFunction 



Name Qualifier 

rncFunctionId READ-ONLY, M 



Description 

An attribute whose 'name-i-value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance within 
the scope of its containing (parent) object instance. 



userLabel 



READ-ONLY, M 



A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 
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Table 23: Notifications of RncFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.4.2.2 



MOC NodeBFunctioi 



This Managed Object Class represents NodeB functionality. For more information about the NodeB, see 
3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 24: Attributes of NodeBFunction 



Name 


Qualifier 


Description 


nodeBFunctionId 


READ-ONLY, M 


An attribute whose 'name-nvalue' can be used as an RDN when 
naming an instance of this object class. This RDN uniquely 
identifies the object instance within the scope of its containing 
(parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. 
Inherited from IVIanagedFunction. 


nodeBFunction-IubLink 


READ-ONLY, M 


The value of this attribute shall be the DN of the related lubLink 
instance. This is a reference attribute modelling the role (of the 
association ConnectedTo) that this NodeBFunction is connected to 
0-1 lubLink. 





Table 25: Notifications of NodeBFunction 




Name 


Qualifier 


Notes 


notifyAckStateChanged 


M, See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 








6.4.2.3 



MOC UtranCell 



This Managed Object Class represents a radio cell controlled by the RNC. For more information about radio cells, see 
3GPPTS 23.002 [15]. 

It inherits from ManagedFunction. 
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Table 26: Attributes of UtranCell 



Name 


Qualifier 


Description 


utranCellld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when 
naming an instance of this object class. This RDN uniquely identifies 
the object instance within the scope of its containing (parent) object 
instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. 
Inherited from ManagedFunction. 


utranCell-IubLink 


READ-ONLY, M 


The value of this attribute shall be the DN of the related lubLink 
instance. This is a reference attribute modelling the role (of the 
association AssociatedWith) that this UtranCell is associated with 0- 
1 lubLink. 



Table 27: Notifications of utranCell 



Name Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.4.2.4 



MOC lubLink 



The 'lub link' managed object is the logical link to a NodeB as seen from the RNC. For more information about the 
RNC, see 3GPP TS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 28: Attributes of lubLink 



Name 


Qualifier 


Description 


iubLinkId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming 
an instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. 
Inherited from ManagedFunction. 


iubLink-UtranCell 


READ-ONLY, 


The value of this attribute shall be a list of the DN(s) of the related 
UtranCell instance(s). This is a reference attribute modelling the role (of 
the association AssociatedWith-1) that this lubLink is associated with 0- 
N UtranCells. 


iubLink-NodeBFunction 


READ-ONLY, M 


The value of this attribute shall be the DN of the related NodeBFunction 
instance. This is a reference attribute modelling the role (of the 
association ConnectedTo) that this lubLink is connected to 0-1 
NodeBFunction. 





Table 29: Notifications of lubLlnk 




Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







not if yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyOb ject Creation 







notifyOb jectDeletion 
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6.4.2.5 



MOC MscFunctioi 



This Managed Object Class represents MSC functionality. For more information about the MSC, see 3GPP TS 23.002 
[15]. 



It inherits from ManagedFunction. 



Table 30: Attributes of MscFunction 



Name 



Qualifier 



Description 



mscFunctionId READ-ONLY, M 



userLabel 



READ-ONLY, M 



An attribute whose 'name-nvalue' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance within 

the scope of its containing (parent) object instance. 

A user-friendly (and user assigned) name of the associated object. Inherited from 
IVIanagedFunction. 



Table 31 : Notifications of MscFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.1 1 1 -2 [1 1]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 








6.4.2.6 



MOC HlrFunctioi 



This Managed Object Class represents HLR functionality. For more information about the HLR, see 3GPP TS 23.002 
[15]. 



It inherits from ManagedFunction. 



Table 32: Attributes of HlrFunction 



Name 



Qualifier 



Description 



hlrFunctionld READ-ONLY, M 



userLabel 



READ-ONLY, M 



An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 

within the scope of its containing (parent) object instance. 

A user-friendly (and user assigned) name of the associated object. Inherited from 
IVIanagedFunction. 



Table 33: Notifications of HlrFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notifyChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyObjectCreation 







notifyObjectDeletion 








6.4.2.7 



MOC VlrFunctioi 



This Managed Object Class represents VLR functionality. For more information about the VLR, see 3GPP TS 23.002 
[15]. 
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It inherits from ManagedFunction. 



Table 34: Attributes of virFunction 



Name 


Qualifier 


Description 


vlrFunctionld 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 35: Notifications of virFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.4.2.8 



MOC AucFunctioi 



This Managed Object Class represents AUC functionahty. For more information about the AUC, see 3GPP TS 23.002 
[15]. 



It inherits from ManagedFunction. 



Table 36: Attributes of AucFunction 



Name 


Qualifier 


Description 


aucFunctionId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 37: Notifications of AucFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yNewAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyOb ject Creation 







notifyOb jectDeletion 








6.4.2.9 



MOC EirFunctioi 



This Managed Object Class represents EIR functionality. For more information about the EIR, see 3GPP TS 23.002 
[15]. 

It inherits from ManagedFunction. 
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Table 38: Attributes of EirFunction 



Name 


Qualifier 


Description 


eirFunctionId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 39: Notifications of EirFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11 -2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAl arm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.4.2.10 



MOC SmsIwmscFunction 



This Managed Object Class represents SMS-IWMSC functionality. For more information about the SMS-IWMSC, see 
3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 40: Attributes of SmsIwmscFunction 



Name 


Qualifier 


Description 


SmsIwmscFunction Id 


READ-ONLY, M 


An attribute whose 'name-i-value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from IVIanagedFunction. 



Table 41 : Notifications of SmsIwmscFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yNewAl arm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyOb ject Creation 







notifyOb jectDeletion 








6.4.2.11 



MOC SmsGmscFunctioi 



This Managed Object Class represents SMS-GMSC functionality. For more information about the SMS-GMSC, see 
3GPPTS 23.002 [15]. 

It inherits from ManagedFunction. 
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Table 42: Attributes of SmsGmscFunction 



Name 


Qualifier 


Description 


SmsGmscFunction Id 


READ-ONLY, M 


An attribute whose 'name-nvalue' can be used as an RDM when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from IVIanagedFunction. 



Table 43: Notifications of SmsGmscFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAl arm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.4.2.12 



MOC GmscFunctioi 



This Managed Object Class represents GMSC functionality. For more information about the GMSC, see 
3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 44: Attributes of GmscFunction 



Name 


Qualifier 


Description 


gmscFunctionId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from ManagedFunction. 



Table 45: Notifications of GmscFunction 



Name 


Qualifier 


Notes 


notifyAckStateGhanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueGhange 







notif yGhangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyGlearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yNewAl arm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyOb ject Great ion 







notifyOb jectDeletion 








6.4.2.13 MOC SgsnFunction 

This managed object class represents SGSN functionality. For more information about the SGSN, see 3GPP TS 23.002 
[15]. 

It inherits from ManagedFunction. 
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Table 46: Attributes of SgsnFunction 



Name 


Qualifier 


Description 


SgsnFunction Id 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from IVIanagedFunction. 



Table 47: Notifications of SgsnFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notif yNewAl arm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.4.2.14 MOC GgsnFunction 

This Managed Object Class represents GGSN functionality. For more information about the GGSN, see 

3GPPTS 23.002 [15]. 



It inherits from ManagedFunction. 



Table 48: Attributes of GgsnFunction 



Name 


Qualifier 


Description 


ggsnFunctionId 


READ-ONLY, M 


An attribute whose 'name-i-value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object 
instance within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited 
from ManagedFunction. 



Table 49: Notifications of GgsnFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyNewAlarm 


See Alarm IRP (3GPP TS 32.111-2 [11]) 




notifyOb ject Creation 







notifyOb jectDeletion 








6.4.2.15 MOC BgFunction 

This Managed Object Class represents BG functionality. For more information about the BG, see 3GPP TS 23.002 [15]. 

It inherits from ManagedFunction. 
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Table 50: Attributes of BgFunction 



Name 


Qualifier 


Description 


bgFunctionId 


READ-ONLY, M 


An attribute whose 'name+value' can be used as an RDN when naming an 
instance of this object class. This RDN uniquely identifies the object instance 
within the scope of its containing (parent) object instance. 


userLabel 


READ-ONLY, M 


A user-friendly (and user assigned) name of the associated object. Inherited from 
ManagedFunction. 



Table 51 : Notifications of BgFunction 



Name 


Qualifier 


Notes 


notifyAckStateChanged 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyAttributeValueChange 







notif yChangedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notifyClearedAlarm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




notif yNewAl arm 


See Alarm IRP (3GPP TS 32.1 11-2 [11]) 




not ifyObject Great ion 







notifyOb jectDeletion 








6.4.3 Associations 



6.4.3.1 



Association ConnectedTo (M) 



This bi-directional association models the relationship between the lubLink and NodeB (through the NodeBFunction). 
It has two roles, named lubLink-NodeBFunction and NodeBFunction- lubLink. These two roles model each MOC's 
association with the other MOC. Each role is in the MOC definition mapped to a reference attribute with the same 
name. 



6.4.3.2 



Association Associatedwith-l (O) 



This bi-directional association models the relationship between the lubLink and UtranCell. It has two roles, named 
lubLink-UtranCell and UtranCell-IubLink. These two roles model each MOC's association with the other MOC. This 
association is optional, but under the condition that at least one of the associations AssociatedWith-1 and 
AssociatedWith-2 shall be present in each instance of Utran Cell. Each role is in the MOC definition mapped to a 
reference attribute with the same name. 
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Annex A (informative): 

Supported UIVITS network configurations 

Figure A. 1 depicts four typical network configurations, which are supported by the UMTS NRM over the Itf-N. 
However, this does not preclude support for other configurations. 



NM 



Itf-N 





NodeB 







NodeB 



Single 

RNCor 

NodeB 



Config. 1 



Config. 2 



Config. 3 



Config. 4 



Figure A.1 : Typical network configurations supported by the R99 UIVITS NRM 

Table A.l shows the possible number of instances in R99 for each network configuration (counted from left to right in 
figure A. 1.): 
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Table A.I : Number of instances for each R99 example configuration in figure A.I 



MOC 


Config. 1 


Config. 2 


Config. 3 


Config. 4 


GSSubNetwork 


1 


1 


1 


0..1 


ManagementNode 


1 


1 








GSManagedElement 


1..N 


1..N 


1..N 


1 


MeContext 


0..M 


0..M 


0..M 


0..1 


RncFunction 


0..P 


0..P 


0..1 


0..1 


NodeBFunction 


0..Q 


0..Q 


0..{N-1) 


0..1 


lubLink 


0..Q 


0..Q 


0..(N-1) 





UtranCell 


0..R 


0..R 


0..R 


0..R 


IRPAgent 


1 


1 


1 


1 


NotificationIRP 


1 


1 


1 


1 


AlarmlRP 


0..1 


0..1 


0..1 


0..1 


BasicCmIRP 


0..1 


0..1 


0..1 


0..1 
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Annex B (normative): 

Event Types and Extended Event Types 

This annex lists and explains Event Types and Extended Event Types used by Basic CM IRP and then lists the Event 
Types and Extended Event Types valid for each notification in this IRP. 

Event Type is carried by a parameter called eventType defined in Notification IRP IS (3GPP TS 32.106-2 [3]). 

Extended Event Type is carried by a parameter called extendedEventType defined in Notification IRP IS (3GPP 
TS 32.106-2 [3]). 

Encoding of eventType and extendedEventType is Solution Set dependent. For example, the value of 
eventType may be encoded as an Object Identifier in the CMIP SS and as a numeric string in the CORBA SS. 

The tables below may be extended in the future. 

Table B.I : Event Types 



Event Types 



Explanation 



Object creation 



A notification of this type indicates that a new managed object instance has been created 
(as defined in ITU-T X.721 [8] and ITU-T X.730 [9]). 



Object deletion 



A notification of this type indicates that a managed object instance has been deleted (as 
defined in ITU-T X.721 [8] and ITU-T X.730 [9]). 



Attribute value change 



A notification of this type indicates that the value(s) of one or more attributes have 
changed (as defined in ITU-T X.721 [8] and ITU-T X.730 [9]). 



Table B.2: Extended Event Types 



Extended Event Types 


Explanation 




In this release of the present specification, no Extended Event Types are used. Thus, this 
mandatory parameter from [3] is set to NULL in all notifications defined in this 
specification. 



Table B.3: Event types and Extended Event Types applicable to each Notification 


■*•—-- Notification 


Event Type 


Extended Event type 


notifyOb jectCreation 


Object creation 


NULL 


not ifyObject Deletion 


Object deletion 


NULL 


notifyAttributeValueChange 


Attribute value change 


NULL 
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Annex C (informative): 
Change history 



Change history 


Date 


TSG# 


TSG Doc. 


CR 


Rev 


Subject/Comment 


Old 


New 


Dec 2000 


S_10 


SP-000513 


- 
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2.0.0 


3.0.0 


Mar 2001 


S_11 


SP-010029 


001 




UMTS Network Resource Model alignment with TSG RAN 
specifications 


3.0.0 


3.1.0 


Mar 2001 


S_11 


SP-010029 


002 




Correction of notifyObjectDeletion and notifyObjectCreation behaviour 
description 


3.0.0 
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